Because of copyright infringement and piracy concerns, there is desired secure methods and devices for the transmission and reception of legally protectable content or data over a communication channel. More specifically, and as an example, due to the copyright concerns of content owners, there is a need for secure transmission of digital content from digital media to a corresponding display, such as a digital versatile disk (“DVD”) player on a computer to the computer display. In order to secure the Audiovisual content, the transmission between the transmitter of the DVD player and the receiver of the display can be encrypted and decrypted using an appropriate cryptographic algorithm. Cryptographic algorithms typically require one or more secret encryption/decryption keys to operate. It is the secure storage of these secret device keys that is the focus of this invention. The following abbreviations for certain cryptography related terms are used herein:
AESAdvanced Encryption StandardAKEAuthentication & Key ExchangeCCICopy Control InformationCEKContent-Encryption KeyDCPDigital Content Protection, LLCDDCDisplay Data ChannelDESData Encryption StandardDHDiffie-HellmanDTCPDigital Transmission Content ProtectionDTLADigital Transmission Licensing AuthorityDVIDigital Visual InterfaceHDCPHigh-bandwidth Digital Content Protection SystemHDMIHigh-Definition Multimedia InterfaceI2CInter-Integrated Circuit BusKEKKey-Encryption KeyKSVKey Selection VectorNVMNon-Volatile MemoryPGPPretty Good PrivacyPRNGPseudo Random Number GeneratorRSARivest, Shamir, Adleman
As used herein, NVM is used to refer to any type of read only memory (“ROM”), rigid disk drive, or optical disk drive. For example ROM includes programmable ROM (“PROM”), electrically erasable programmable ROM (“EEPROM”), ultra-violet (“UV”) erasable programmable ROM, flash memory, video BIOS (“VBIOS”), ROM BIOS, or EDID ROM. Further, rigid disk drive (“RDD”) includes floppy disk drive (“FDD”), hard disk drive (“HDD”), zip drive, or LS-120 Drive or Super Drive. Optical disk drive includes CD drive (“CD-ROM”, “CD-RW”, “CDC-R”), DVD drive (“DVD-ROM”, “DVD-RW”, “DVD-RAM”, “DVD-R”, “DVD-WO”) or magneto-optical (“MO”) drive.
In the case of the transmission and reception of copy-protected Audiovisual content, the “High-bandwidth Digital Content Protection System” V1.0 and V1.1 specification requires that each HDCP-enabled transmitter and receiver device be assigned and use a unique set of secret device keys for the HDCP cipher process. Under the HDCP specification, each device key set consists of a non-secret 40-bit KSV and forty 56-bit secret keys, requiring a total of 2280 bits or 285 bytes for storage. For an HDCP transmitter with an upstream protocol described by the “Upstream Link for the High-bandwidth Digital Content Protection System” V0.90 (“ULHDCPS”) from Intel, two device key sets are required. The HDCP specification and the ULHDCPS protocol are both incorporated herein by reference. Each of these protocols has a process for authentication and a process for exchange of keys. Authentication is a cryptographic process for verifying that a device is authorized or licensed to handle protected content. Key exchange is a cryptographic process for establishing a shared secret key between devices. CCI specifies the conditions under which a copy of copyrighted content can be made.
The following is a general description of the overall key protection procedure conventionally used in an HDCP compliant system. These activities are performed by (1) a key licensing authority, such as DCP, (2) an end-equipment manufacturer, such as a DVD player manufacturer or display manufacturer, and (3) a component vendor such as a maker of chips. The key licensing authority, such as DCP, performs certain activities. First, DCP generates multiple HDCP device key sets for a party or entity, typically the end-equipment manufacturer. In certain circumstances the party or entity receiving the keys from DCP may be a component vendor if the component vendor is embedding the keys in the devices. For purposes of this description, it is assumed that the HDCP device key order is prepared for the end-equipment manufacturer. Then, the entire HDCP device key order is encrypted using the public key of the end-equipment manufacturer prior to being written to a media, such as a CD-R. Lastly, the media, such as the CD-R, storing the encrypted HDCP device key order is sent to the end-equipment manufacturer via common carrier.
The following activities are performed by the component vendor. One or more global key-encryption keys (Kg) are randomly generated and programmed into the silicon devices. A unique content-encryption key (Ku) is randomly generated for each HDCP compliant device This Ku is programmed into each HDCP device by the component vendor during the wafer manufacturing flow. In addition, a shared content-encryption key (Ks) is randomly generated for each end-equipment manufacturer. Each content-encryption key (Ks) is encrypted using Kg. Then one pair of unencrypted and encrypted Ks values is securely sent to each end-equipment manufacturer, for example using a software package compatible with the Open PGP standard.
The following activities are performed by the end-equipment manufacturer. First, each HDCP device key set is encrypted using the shared content-encryption Ks. Next, the encrypted HDCP device key set is programmed into each NVM. Then, the encrypted version of Ks is programmed into the header of each NVM.
The following activities are performed automatically by the HDCP device. The content-encryption key (Ks) embedded in the NVM header is decrypted using Kg. Next, the unencrypted Ks value is used to decrypt the HDCP device key set stored in the NVM. Lastly, the HDCP device key set is re-encrypted using the unique content-encryption key (Ku).
Conventional methods for protecting these internally or externally stored device key sets require large amounts of on-chip NVM resulting in high device cost. Large amounts of on-chip NVM is required to store numerous spare content-encryption keys for renewability purposes. The entities embedding device keys, such as the end-equipment manufacturers or component vendors may desire to renew their device keys for a variety of reasons. The entity may renew the device keys as a matter of course, periodically, for example every six months, or after manufacturing a certain number of products, for example, after every million units, or whenever a new device key set package is received from the key licensing authority. The entities embedding device keys should, as a matter of course, renew the Ks whenever the Ks has been compromised. Device keys are compromised in a variety of methods, such as cryptanalysis, unauthorized disclosure, or accidental disclosure.
A variety of schemes and processes have been developed to address the current shortcomings in device key protection. These include public-key cryptography; Diffie-Hellman key exchange; on-chip key generation logic for content-encryption keys; multiple on-chip content-encryption keys; single on-chip content-encryption key; and key handling software tools.
The advantage of public-key cryptography, e.g., sender-encrypted session key such as RSA, over symmetric-key cryptography, such as DES, is that the private decryption key does not need to be disclosed, for example, to the end-equipment manufacturer. Also, only one on-chip private key is required for implementation, the process supports renewability, key distribution is relatively easy, the session key is used only one time, and the sender can create new session keys independent from recipient. The disadvantage with public-key cryptography is that the algorithm is much more complex, hence implementation requires the highest circuit complexity, more die area resulting in higher device cost, and processing is slow. In addition, this method does not leverage the existing DES cipher engine. Furthermore, public-key cryptosystems are vulnerable to chosen-plaintext attacks.
The advantage with Diffie-Hellman key exchange compared to symmetric-key cryptography, such as DES, is that the private decryption key does not need to be disclosed, for example to the end-equipment manufacturers. In addition, only one on-chip private key is required for implementation, the method supports renewability, key distribution is relatively easy, each session key is used only one time, and the sender can create new session keys independent from the recipient. The disadvantage with Diffie-Hellman key exchange is that the algorithm is much more complex, hence implementation requires the highest circuit complexity, more die area resulting in higher device cost, and processing is slow. In addition, this method does not leverage the existing DES cipher engine. Furthermore, Diffie-Hellman key exchange is vulnerable to man-in-the-middle attack. As can be seen, more traditional approaches for key exchange such as public-key or Diffie-Hellman are mathematically quite complex and disadvantageously are cost prohibitive.
On-chip key generation logic for content-encryption keys attempts to eliminate the cost associated with the on-chip NVM by generating rather than storing the array of content-encryption keys. The on-chip key generation logic for content-encryption keys supports renewability, utilizes exiting DES cipher engine and a smaller internal NVM is required for implementation. As the number of content-encryption keys supported on-chip increases, there will be a crossover point when generating the keys on-chip will require less die area than using a ROM-based lookup table approach. A disadvantage with this approach is that an on-chip NVM is still required to store an array of randomly generated seed values for the PRNG. When using a DES cipher engine to implement the PRNG, these randomly generated seed values include both 56-bit DES keys and 64-bit initialization vectors. Also, the number of seed values required for the life of the product must be predetermined. Thus, using an on-chip key generator may provide a slight reduction in the size of the on-chip NVM, but it does not eliminate the need for the internal NVM. The added circuit complexity of this method outweighs any benefit that might be achieved. Furthermore, the on-chip key generation logic for content-encryption keys method has high circuit complexity, difficult key distribution, session keys are used many times and the sender is dependent on the recipient for issuing new session keys.
The multiple on-chip content-encryption keys method attempts to address the renewability issue by storing multiple content-encryption keys in the on-chip NVM. The multiple on-chip content-encryption keys method advantageously supports renewability and utilizes the existing DES cipher engine. A significant disadvantage associated with this approach is that the number of secret 56-bit content-encryption keys required for the life of the product needs to be predetermined and stored in on-chip NVM. Overestimating the required number of keys wastes die area, which increases the overall device cost. On the other hand, underestimating the required number of keys shortens the life of the product. Other disadvantages of using the multiple on-chip content-encryption keys method includes: high device cost, large internal NVM required, difficult key distribution, the session key is used many times, and the sender is dependent on the recipient for issuing new session keys.
In the single on-chip content-encryption key method, the same DES key is programmed into each content protection device. The single on-chip content-encryption key method is simple thus resulting in low device cost. Also, this method utilizes exiting DES cipher engines. Disadvantageously, the algorithm used by the component vendors to protect the device key sets during the manufacturing process is shared with the end-equipment manufacturers. Component vendors should be extremely reluctant to disclose their one secret DES key to the end-equipment manufacturers as a massive recall of products would be required if the security for this one key was ever comprised. Other disadvantages of the single on-chip content-encryption key method includes no support for renewability, and difficult key distribution.
In addition to the methods described above, hybrid cryptosystems have been developed. These include public-key and symmetric-key hybrid cryptosystems wherein message data is encrypted using symmetric-key cryptography and session key, then a random number is used as the session key; the session key is encrypted using public-key cryptography and the recipient's public key, and the encrypted session key is sent along with encrypted message data.
Another hybrid cryptosystem is the Diffie-Hellman and symmetric-key hybrid cryptosystem wherein message data is encrypted using symmetric-key cryptography and the session key, then a DH secret value is generated using the sender's private value and the recipient's public value. The DH secret value is used as session key and the sender's DH public value is sent along with the encrypted message data. Each of these hybrid systems has advantages and disadvantages similar to those of their component methods.
Disadvantageously, private device key sets issued by key licensing authorities, such as the HDCP device keys issued by DCP for DVI and HDMI applications, are left unprotected throughout most of the manufacturing process. Furthermore, there is well known in the industry a number of techniques and processes for accessing otherwise protected data. These include, but are not limited to ciphertext-only attacks, known-plaintext attacks, chosen-plaintext attacks, adaptive-chosen-plaintext attacks, chosen-key attacks and rubber-hose cryptanalysis.
What is desired is a method for protecting private device key sets, including those issued by key licensing authorities, such HDCP device key sets issued by DCP for DVI and HDMI applications, during the manufacturing process, and otherwise.